reship_stats(summary): pure summary of what a routed run re-shipped. The load-bearing
signal is the SHARD reship ratio (shards shipped / shards present) — appending new big
files ships new SOLOS and leaves shards untouched (~0), so healthy GROWTH never trips it;
re-shipping many whole SHARDS does, which is small-file churn = the uniform-medium-churn
signature Phase 3 (leveling) is for. byte_ratio reported for context only (conflates growth
w/ churn, not the trigger). reship_summary_line for the print+email.

__main__ size-routing completion: prints the reship line; when shard_ratio > 25%
(RESHIP_WATCH_RATIO) flags [RESHIP-WATCH] and the completion email subject/body carry it
(warn-only; the operator decides whether to consider Phase 3 for that target).

Tests test_reship_monitor.py (7): append -> no watch, wide shard churn -> watch, strict
25% threshold, all-solos never watches, byte-ratio math, empty target, summary line.
Suite 238 -> 245. Based on main, not stacked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…e Phase-3 trigger)

Slice 4's [RESHIP-WATCH] email line is a fleeting per-run signal: it fires once
routing is enabled, cries wolf on a one-off re-processing pass, and rides in a
routine email the operator tunes out. Make it a DURABLE, de-noised, queryable
trigger instead.

- update_reship_watch(prior_watch, stats, run_epoch, sustain=3): pure fold of a
  run's reship_stats into a streak block persisted in the target's manifest —
  consecutive_trips (+1 on a tripped run, reset to 0 on a quiet one), sustained
  (>= sustain runs), sustained_since, last_ratio/last_run/shards_*, and an
  `alerted` idempotency latch OWNED BY the deployment alerter (engine only
  preserves it across trips, clears it on reset so a re-crossing re-alerts once).
- route_and_ship computes the watch over the final post-prune object set and
  always writes the manifest once at the end (records a streak RESET even on an
  all-skipped run). Adds reship_watch to the return dict.
- __main__ surfaces the streak (N/sustain, SUSTAINED?) in the completion print +
  email so a single trip reads as "not yet sustained", not an action item.

The Phase-3 alert (a Teams @mention, fired once on crossing into sustained) is
deployment glue that reads this manifest field — kept out of the engine.

Tests: 9 pure-function cases (mock summary dicts + prior blocks: increment,
reset, sustain-after-N, alerted latch preserve/clear, custom sustain, end-to-end
from reship_stats) + 3 persistence cases in route_and_ship (persist+reset,
append-does-not-accumulate, repeated-churn-sustains). Suite 245 -> 257.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…nag cadence)

The durable watch carries two alerter-owned latch fields, alerted + alerted_at
(when the deployment alerter last @mentioned). The engine treats both as opaque:
preserve across tripped runs, clear on streak reset. This lets the alerter re-nag
on a low cadence while a watch stays sustained without the timer being erased by
an intervening routed run. Suite 257 -> 258.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>